A conventional transmission method of digital data includes a data transmission method based on IEEE1394 (IEEE1394-1995, Standard for a High Performance Serial Bus) serial bus interface standard (hereafter referred to as “IEEE1394”). As for a communication using this data transmission method, two types of communications exist: an Isochronous communication suitable for a data transmission in which it is required to keep a data transmission rate constant as in a case of sending video signals and audio signals or the like; and an Asynchronous communication for a data transmission in which it is required to communicate without fail and it does not matter whether the data transmission rate is constant or not as in a case of sending control signals or the like. It is also possible to mix a single unit of data of the both types of communications in the bus IEEE1394.
Here, a brief summary of the IEEE1394, the Isochronous communication and the Asynchronous communication follows.
FIG. 1 is a diagram showing an AV (Audio Visual) protocol stack when the IEEE1394 is used for transmitting digital video signals and digital audio signals. As is shown in FIG. 1, the IEEE1394 is defined as a protocol of a lower layer. Various types of protocols are suggested as a protocol of an upper layer using the lower layer, for example, SBP-2 designed to efficiently transmit a SCSI protocol in the IEEE1394, IP over 1394 for transmitting datagram of IPv4 in the IEEE1394 being conscious of a network and an AV protocol (IEEE 61883) which is conscious of a real-time data transmission like AV information. An AV protocol 102, above all, mounted with many of the digital AV apparatuses, plays the role of an engine for the diffusion of the IEEE1394.
The AV protocol 102 is a protocol mainly aiming at transmitting real-time data such as video and audio using Isochronous packet. The AV protocol 102 consists of three elements: a real-time data transmission 103, a signal transmission procedure 104 and a control signal 105.
The real-time data transmission 103 defines additional information and a method of packetization that are necessary for storing data in various formats into the Isochronous packet and transmitting it via IEEE1394. The signal transmission procedure 104 defines a procedure for establishing an input/output path between apparatuses for exchanging data using the Isochronous packet for the apparatuses connected via the IEEE1394. In this case, a virtual transmission path is established between the apparatuses by using a concept of “plug”. The control signal 105 defines a control signal for controlling the operations of the apparatuses connected via the IEEE1394. This control signal is transmitted via Asynchronous packet.
As is described above, the concept of “plug” is provided as the signal transmission procedure 104 for establishing a logical signal connection in the AV protocol 102. The plug is a virtual concept and has an input plug and an output plug. The aforementioned apparatuses can have a plurality of input plugs and output plugs irrelevantly to physical connectors. To control a signal path by connecting the input plug and the output plug to a data channel is called a connection management.
The following describes a summary of the Isochronous communication and the Asynchronous communication.
FIG. 2 is a packet block diagram of the Isochronous packet in the Isochronous communication. In the Isochronous communication, a data transmission is carried out using the unit of Isochronous packet in FIG. 2. The data size of the Isochronous packet differs according to the transmission rate. The sending side does not transmit data to a specified node but transmits a packet to all the nodes on the bus using channel numbers 0˜63. A receiving node reads the data by selecting a packet of a channel number which it desires to receive. Therefore, it shall be necessary for the sending node and the receiving node to mutually recognize beforehand the channel numbers to be used in the Isochronous communication between the specified nodes.
FIG. 3 is a packet block diagram of the Asynchronous packet in the Asynchronous communication. In the Asynchronous communication, data transmission is carried out using the unit of Asynchronous packet as shown in FIG. 3. The maximum data size of this packet (the maximum payload length) is defined within a range of 512 [bytes] to 4096 [bytes] according to the transmission rate. There are three types of transactions (processing) of “Read” “Write” and “Lock” in the Asynchronous communication. The Read transaction reads out data of a predetermined data length from a target address of the partner node. The Write transaction writes the data of the predetermined data length to the target address of the partner node. The Lock transaction writes the data of the predetermined data length to the target address of the partner node with conditions. The Read transaction and the Write transaction are used mainly for data transmission whereas the Lock transaction is used principally for sending commands or the like.
The following describes a communication sequence in a conventional Asynchronous communication with reference to FIG. 4.
Firstly, a Controller 120 sends an “ALLOCATE command” to a Consumer 140 and reserves a receiving plug of the Consumer 140 (Step 101). The Consumer 140, receiving the “ALLOCATE command”, reserves the plug and sends back an “ACCEPTED response” to the Controller 120 (Step 102).
Next, the Controller 120, receiving the “ACCEPTED response” from the Consumer 140, sends an “ALLOCATE_ATTACH command” to a Producer 130 (Step 103).
Consequently, the Producer 130 connects a Producer port and sends back the “ACCEPTED response” to the Controller 120 (Step 104). The Controller 120, receiving the “ACCEPTED response” from the Producer 130, sends the “ATTACH command” to the Consumer 140 (Step 105). The Consumer 140, receiving the “ATTACH command”, connects a Consumer port and sends back the “ACCEPTED response” to the Producer 130 (Step 106). With the above processing, an Asynchronous Connection is established, and the data transmission is realized (Step 107).
As described before, the Isochronous communication of the real-time data transmission 103 is a data communication method of broadband type which does not specify a receiving apparatus, and all the apparatuses connected to the IEEE1394 can refer to the data in the bus. As for the video data and the audio data, however, there are cases where it is necessary to protect the copyright.
With that, 5CDTCP (Five Company Digital Transmission Content Protection) (hereafter accordingly referred to as DTCP) has been established as a system to protect digital content sent and received between the apparatuses connected via the IEEE1394. The DTCP authenticates in advance whether processing of encryption/decryption can be handled correctly between a sending apparatus and a receiving apparatus so as to send and receive the data by encrypting the digital content using a method that is available only for the sending apparatus and the receiving apparatus when the digital content with the copy restriction is sent and received.
The following describes a protecting method for contents under the DTCP based on the IEEE1394 with reference to FIG. 5.
FIG. 5 is a schematic diagram of a communication sequence regarding a device authentication and an exchange of encryption keys. The DTCP with the use of the IEEE1394 is defined with an assumption that the data transmission (hereafter referred to as “Isochronous transmission”) is carried out using the Isochronous packet. A data receiving apparatus becomes capable of receiving data from the time when it is connected to the bus and the data is transmitted to the bus since the Isochronous transmission is a broadband type transmission method as mentioned before.
As shown in FIG. 5, when the digital content with a copy restriction is sent with the Isochronous transmission method under the DTCP, firstly a Sink 140, the receiving side, issues a device authentication request to a Source 130, the sending side (Step 121). In this case, the Sink 140 sends a parameter of the receiving side towards the Source 130. The Source 130 sends a parameter of the sending side to the Sink 140 when the received parameter is correct. On the contrary, the Source 130 sends a notification which aims at rejecting the data transmission when the received parameter is not correct. A shared authentication key is calculated respectively when the parameters are exchanged between the sending side and the receiving side (Steps 123 and 126). The Source 130 encrypts an encryption key for encrypting the content using the calculated authentication key when the calculation of the authentication key is terminated (Step 124) and sends the encrypted key to the Sink 140 (Step 125). The side of the Sink 140 decrypts the received encryption key based on the calculated authentication key (Step 127). The Source 130 encrypts the content using the encryption key and sends the encrypted content (Step 129) whereas the Sink 140 decrypts the received encrypted content (Step 130). In this way, the protection of the content or the like at the time of transmission is operated in the conventional Isochronous transmission.
As described above, in the case of using the IEEE1394, the protection for the content under the DTCP presupposes that the Isochronous transmission is employed and thereby nothing is defined for the Asynchronous transmission. For the Isochronous transmission, an aim is to send the content in which a copyright of mainly a video stream and audio data is emphasized, whereas the Asynchronous transmission requires a cumbersome control procedure and a processing speed becomes low when commands and the data stored in an external storage are encrypted at the time of transmission. Also, due to a specified node ID defined for the transmission, the specification in which an apparatus other than the one with the specified node ID cannot receive the data can be considered as one of the reasons for the low processing speed.
However, recently, there has been an increase in the number of occasions to handle still picture data with which an industrial design of a content creator such as PDF (Portable Document Format, a trademark of Adobe) can be recreated and also the still picture data with which a problem of rights of portrait becomes an issue as with an object such as high quality image data. Therefore, a content protection for such data is necessary. It is conceivable that a malicious apparatus located somewhere in the bus lies about its own node ID so as to exploit data unless the data protection is performed.
Consequently, there arises the case in which a data protection for the transmission is necessary even for the data to be transmitted preferably by Asynchronous transmission rather than Isochronous transmission. As for the protecting method, taking into consideration the fact that many AV apparatuses having the IEEE1394 bus are available on the market, it is desirable that the transmission method needs a relatively little modification and is efficient at the same time. Namely, a transmission method that can realize an Asynchronous transmission taking over the content protection method of the DTCP realized with the Isochronous transmission is desired.
Also, an application of the DTCP to USB (DTCP Volume 1 Supplement A Informational Version/Mapping DTCP to USB) is standardized as an example of applying the content protection method of the DTCP to the asynchronous transmission. Furthermore, as is published in Japanese Laid-Open Patent Application 2001-333130, a method of converting the IEEE1394 into the USB is suggested. However, in the case of the USB, different from that of the IEEE1394, a function sharing between a host apparatus and peripheral apparatuses is provided, and it is the host apparatus who manages all the controls of the apparatuses being connected. For example, when a printer is connected to a personal computer, the personal computer controls the peripheral apparatuses via software known as a driver which performs a control specific to each apparatus. In this case, the driver handles the control of the peripheral apparatuses on a one-to-one basis because each peripheral apparatus maker provides a driver uniquely.
However, in a case of using an AV apparatus, such as a digital TV, that is different from a personal computer, it is difficult to perform a control specific to each peripheral apparatus with the use of a driver. Therefore, it is desirable to apply the data transmission utilizing the IEEE1394 interface which has versatility, for instance, in the case of connecting the AV apparatus to a printer.
Nevertheless, there are several challenges in appropriating the cryptographic protocol of the DTCP defined in the Isochronous transmission with the use of the IEEE1394 directly for the Asynchronous transmission.
Firstly, in the case of Isochronous transmission, the encryption key shall be updated regularly every 30 seconds to 2 minutes, and information on the changing timing is stored in an O/E (Odd/Even) field 141 which is a head part of the Isochronous packet as shown in FIG. 2. Therefore, there is no chance that the changing timing at the sending side and the receiving side mismatch even though the time of changing the encryption keys are not completely at regular intervals. In the Asynchronous transmission, however, a free space for a flag to notify the change of the encryption keys does not exist in the data packet as shown in FIG. 3. What is more, the part corresponding to the O/E field 141 is not defined.
Furthermore, in the case of Asynchronous transmission, time and amount of data transmission are not in a proportional relationship, which is different from the Isochronous transmission, and the transmission of enormous amount of data with a fixed transmission rate is not assured. This means that the data transmitted within a certain time under the Isochronous transmission has a specified amount whereas this is not assured in the case of Asynchronous transmission. The size of the data to be transmitted differs according to the content or the like. Therefore, in the case of changing the encryption keys, it is necessary that the sending side and the receiving side recognize with which timing the encryption keys should be changed.
In the case of Isochronous transmission, a unit used for encryption is defined one-sidedly according to the content to be sent. The unit used for encryption is determined according to the data transmission rate of respective contents. In the Asynchronous transmission, however, the transmission rate has no meaning and the amount of the data to be transmitted varies greatly. Therefore, there are no criteria for a unit that is the most suitable for encryption, and it can be set freely between 8 bytes and 1023 bytes in the case of applying the DTCP to the USB. In the case of using a personal computer which mainly utilizes the USB, a type of apparatus for the receiving side may be registered beforehand to the sending side, as described above. However, as for an AV apparatus with which the IEEE1394 is mainly used, it is not allowed to take the required steps to register a parameter according to the apparatus being connected. Consequently, there is a need for the sending side and the receiving side to share a unit of encryption in one way or another.
For the above reasons, a solution different from the case of Isochronous transmission is required in order to apply the DTCP method to the IEEE1394 Asynchronous communication.
The present invention therefore takes the above challenges into consideration and aims to provide a data transmission system that allows a copyright protection of contents in the conventional Asynchronous transmission employing the IEEE1394.